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Abstract 

Providing  system  interoperability  and  evolving  technologies  in  major  DoD  systems  are 
two  important  acquisition  challenges  in  preparing  the  military  to  meet  current  and  future 
demands.  The  Acoustic  Rapid  COTS  Insertion  (ARCI)  program  successfully  addressed  many  of 
the  associated  challenges.  That  program  was  studied  as  the  basis  for  modeling  the  planned 
Rapid  Capability  Insertion  Process  (RCIP)  approach  for  continuous,  reduced-cost  upgrading  of 
assets.  ARCI  used  atypical  methods  in  the  face  of  atypical  program  requirements  and 
conditions.  A  previously  developed  acquisition  program  model  was  adapted  to  reflect  ARCI  and 
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used  for  model  validation.  This  model  was  then  changed  to  reflect  the  basic  conditions  expected 
to  be  faced  by  RCIP  programs.  The  model  demonstrated  the  potential  of  RCIP  to  significantly 
improve  program  performance.  However,  implementation  risks  are  identified  that  may  degrade 
potential  performance,  including  increased  oversight,  the  use  of  more  new  development,  and 
the  resulting  integration  scope  and  risk.  When  incorporated  into  the  model,  these  risks  were 
shown  to  significantly  decrease  RCIP  performance.  Means  for  successfully  managing  the  RCIP 
design  based  on  the  ACRI  program  and  RCIP  operations  are  suggested  for  use  in  addressing 
the  identified  implementation  risks. 

Introduction 

Providing  system  interoperability  and  evolving  technologies  in  major  DoD  systems  are 
two  important  acquisition  challenges  in  preparing  the  military  to  meet  current  and  future 
demands.  The  use  of  legacy  and  other  weapons  platforms,  joint  Service  solutions,  the 
information  and  communication  needs  of  Network  Centric  Systems  (NCS),  and  coordination 
with  allies  in  joint  operations  require  the  development  of  weapons  systems  that  can  operate 
across  system,  platform,  and  systems-of-systems  boundaries.  Traditional  DoD  acquisition 
approaches  do  not  fully  provide  the  interoperability  and  development  speed  needed  to  meet 
these  demands.  The  continued,  and  in  some  cases  accelerating,  evolution  of  technologies 
continuously  creates  new  challenges  that  are  difficult  to  forecast  and  require  fast  acquisition 
response.  Threat  matrices  also  evolve,  changing  the  capabilities  required  to  meet  them.  Short 
capability  improvement  cycle-times  are  needed  to  respond  to  these  moving  targets  for 
acquisition  efforts.  The  development  of  an  Integrated  Weapons  System  (IWS)  for  surface  ships 
is  an  example  of  a  major  acquisition  effort  to  provide  system  (and  platform)  interoperability  and 
exploit  technology  evolution  to  meet  changing  threats.  The  current  work  focuses  on  acquisition 
approaches  to  meet  these  challenges. 

Naval  Open  Architecture  (OA)  (DAU,  2009)  is  a  breakthrough  acquisition  approach  that 
develops  and  facilitates  the  use  of  acquisition  processes,  which  integrate  interoperable  systems 
that  evolve  with  technologies,  threats,  and  program  environments  (e.g.,  funding).  OA  does  this 
through  five  principles:  1)  modular  design  and  design  disclosure,  2)  reusable  application 
software,  3)  interoperable  joint  warfighting  applications  and  secure  information  exchange,  4) 
lifecycle  affordability,  and  5)  encouraging  competition  and  collaboration  through  the 
development  of  alternative  solutions  and  sources.  Evolutionary  Acquisition  (EA)  (DAU,  2009)  is 
a  somewhat  recently  developed  acquisition  approach  that  uses  the  repeated  integration  of  only 
mature-enough  technologies  into  products  to  speed  capability  improvement  for  warfighters.  OA 
and  EA  can  act  synergistically  to  meet  their  objectives.  However,  effective  implementation  is 
critical  for  success.  Particularly  in  large,  complex  systems  that  span  platforms,  the  successful 
implementation  of  OA  and  EA  is  not  obvious  or  easy. 

Despite  their  potential,  OA  and  EA  have  not  yet  been  fully  developed  or  implemented  in 
DoD  acquisition.  Previous  research  (Ford  &  Dillard,  2008;  Dillard  &  Ford,  2007)  suggests  that 
the  DoD  can  successfully  integrate  open  systems  and  Evolutionary  Acquisition.  This  supports 
the  Navy’s  current  development  of  the  Rapid  Capability  Insertion  Process  (RCIP)  to  implement 
Open  Architecture  and  Evolutionary  Acquisition  (described  later).  The  Navy’s  Acoustic  Rapid 
COTS  (commercial  off-the-shelf)  Insertion  program  (ARCI)  experience  (described  later) 
demonstrates  that  these  approaches  can  be  integrated  and  applied  successfully.  An  improved 
understanding  of  how  OA  and  EA  have  been  used  successfully  and  can  be  used  in  RCIP  is 
needed  to  better  apply  them  across  systems  and  platforms  and,  thereby,  improve  acquisition 
programs. 
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The  Research  Approach 

Evolutionary  Acquisition  and  open  systems  approaches  combine  to  create  a  complex  set 
of  development  processes  that  evolve  over  time.  An  improved  understanding  of  these 
processes  and  their  management  is  available  through  formal  modeling  of  the  most  important 
components  and  relationships  that  drive  system  performance  and  risk.  Due  to  the  number  and 
complexity  of  the  components  and  their  relationships,  the  formal  model  structure  and  rigor  of 
calculations  can  simulate  and  forecast  performance  and  risk  better  than  informal,  tacit 
predictions  by  humans.  Therefore,  we  applied  a  computational  experimentation  approach  to 
investigating  Evolutionary  Acquisition  and  open  systems  projects,  integrating  theory  and 
practice  in  a  computational  tool  that  allows  controlled  experimentation  through  simulation. 

Previous  research  and  modeling  of  Open  Architecture  and  Evolutionary  Acquisition  is 
being  used  as  the  foundation  of  the  current  work.  That  model  was  first  revised  and  improved  to 
reflect  the  ARCI  program  to  develop  a  basis  for  understanding  success  factors  in  OA  and  EA 
implementation.  This  required  the  development  of  a  deep  understanding  of  the  relevant  aspects 
of  the  ARCI  acquisition  program  (summarized  next).  The  ACRI  model  was  then  revised  to 
reflect  the  Rapid  Capability  Insertion  Process.  Model  analysis  was  used  to  better  understand  the 
requirements  for  success  in  RCIP. 

The  System  Dynamics  Modeling  Methodology 

The  system  dynamics  methodology  was  applied  to  model  the  ARCI  program.  System 
dynamics  is  one  of  several  established  and  successful  approaches  to  systems  analysis  and 
design  (Flood  &  Jackson,  1991;  Lane  &  Jackson,  1 995;  Jackson,  2003).  The  methodology  has 
been  extensively  used  for  this  purpose,  including  to  study  several  aspects  of  development 
projects.  System  dynamics  shares  many  fundamental  systems  concepts  with  other  systems 
approaches,  including  emergence,  control,  and  layered  structures.  Therefore,  system  dynamics 
can  address  issues  such  as  risk  in  large  complex  systems  such  as  the  DoD  acquisition  projects 
(Lane,  Grofller  &  Milling,  2004).  The  methodology’s  ability  to  model  many  diverse  system 
components  (e.g.,  work,  people,  money,  information),  processes  (e.g.,  design,  technology 
development,  quality  assurance,  rework),  and  managerial  decision-making  and  actions  (e.g., 
forecasting,  resource  allocation)  makes  it  useful  for  investigating  acquisition  programs.  Forrester 
(1961)  develops  the  methodology's  philosophy,  and  Sterman  (2000)  specifies  the  modeling 
process  with  examples  and  describes  numerous  applications. 

The  system  dynamics  methodology  applies  a  control  theory  perspective  to  the  design 
and  management  of  complex  human  systems.  The  perspective  focuses  on  how  the  internal 
structure  of  a  system  impacts  managerial  behavior  and  performance  over  time.  The  system 
dynamics  approach  is  unique  in  its  integrated  use  of  stocks  and  flows,  causal  feedback,  and 
time  delays  to  model  structures  and  policies.  Stocks  represent  accumulations  or  backlogs  of 
work,  people,  information,  or  other  portions  of  the  system  that  change  over  time.  Flows 
represent  the  movement  of  those  commodities  into,  between,  and  out  of  stocks.  For  example. 
Figure  1  shows  a  simple  stock  and  flow  diagram  of  one  possible  arrangement  of  the  backlogs 
and  movements  of  work  within  a  single  activity  (e.g..  Advanced  Development)  of  an  acquisition 
program.  Stocks  are  represented  by  boxes.  Flows  are  represented  by  arrows  between  the 
boxes  with  the  valve  symbols.  Arrowheads  indicate  the  direction  of  movement  of  the  work. 
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Figure  1.  A  Stock  and  Flow  Diagram  of  Work  Backlogs  and  Development  Activities 

Feedback  is  modeled  conceptually  in  system  dynamics  with  causal  loop  diagrams. 

Figure  2  shows  a  portion  of  a  causal  loop  diagram  for  a  single  activity  of  an  acquisition  program. 
In  causal  loop  diagrams,  arrows  indicate  the  direction  of  causal  influence.  The  variable  at  the  tail 
of  an  arrowhead  influences  the  variable  at  the  head  of  the  arrow.  A  plus  sign  at  an  arrowhead 
indicates  that  the  impacted  variable  and  driving  variable  move  in  the  same  direction  (i.e.,  an 
increase  in  the  driving  variable  increases  the  impacted  variable,  and  a  decrease  in  the  driving 
variable  decreases  the  impacted  variable).  A  negative  sign  at  an  arrowhead  indicates  that  the 
impacted  variable  and  driving  variable  move  in  opposite  directions  (i.e.,  an  increase  in  the 
driving  variable  decreases  the  impacted  variable,  and  a  decrease  in  the  driving  variable 
increases  the  impacted  variable).  The  two  types  of  feedback  loops  are  also  illustrated  in  Figure 
2.  A  balancing  loop  (“B”  in  Figure  2)  tends  to  control  or  limit  the  movement  of  the  variables  in  the 
loop.  In  contrast,  a  reinforcing  loop  (“R”  in  Figure  2)  tends  to  move  systems  farther  and  farther 
from  their  initial  conditions  at  faster  and  faster  speeds.  The  behavior  pattern  generated  by  a 
specific  feedback  loop  (e.g.,  exponential  growth  or  movement  toward  a  target)  can  be  identified 
by  sequentially  tracing  these  impacts  on  variables  through  the  series  of  causal  links  that 
describe  the  loop.  See  Sterman  (2000)  for  a  detailed  description  of  the  building  and  use  of 
causal  loop  diagrams. 
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Feedback  Loop  Legend 

B  -  Rework  backlog  increases  rework  rate,  controlling  the  size  of  the  backlog 
R  -  Poor  quality  rework  increases  the  work  fraction  requiring  rework  and  rework  backlog,  further 
increasing  the  amount  of  work  requiring  rework 

Figure  2.  A  Causal  Loop  Diagram  of  a  Portion  of  an  Advanced  Development  Phase 

Stock  and  flow  diagrams  and  causal  loop  diagrams  can  be  integrated  into  system 
structure  diagrams  that  simultaneously  describe  the  feedback  and  accumulation/flow  nature  of 
the  system  being  modeled.  Figure  3  shows  a  system  structure  diagram  of  a  model  of  an 
acquisition  program  phase.  The  diagram  integrates  the  stock  and  flow  diagram  in  Figure  1,  the 
causal  loop  diagram  in  Figure  2,  and  some  of  the  other  important  portions  of  the  system.  The 
feedback  loop  legend  briefly  describes  how  each  feedback  loop  structure  creates  system 
behavior. 
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Feedback  Loop  Legend  (partial) 

B1  -  An  increase  in  the  Initial  Design  Backlog  increases  the  initial  design  rate,  thereby 
controlling  the  backlog 

B2  -  An  increase  in  the  Quality  Assurance  (QA)  Backlog  increases  the  QA  rate  and 
discovery  of  rework,  thereby  controlling  the  backlog 

B1  -  An  increase  in  the  Quality  Assurance  (QA)  Backlog  increases  the  QA  rate  and 
design  approval  rate,  thereby  controlling  the  backlog 

B4  -  An  increase  in  the  Rework  Backlog  increases  the  rework  rate,  thereby  controlling 
the  backlog 

B5  -  An  increase  in  the  accumulation  of  approved  designs  increases  the  size  of  the 
design  release,  thereby  controlling  the  Approved  Design  accumulation 
B6  -  An  increase  in  the  Quality  Assurance  (QA)  Backlog  increases  the  QA  rate, 
discovery  of  rework,  fraction  discovered,  and  approval  rate,  thereby  controlling  the 
backlog 

R1  -  An  increase  in  the  Quality  Assurance  (QA)  Backlog  increases  the  QA  rate, 
discovery  of  rework.  Rework  Backlog,  and  rework  rate,  thereby  increasing  the  QA 
Backlog  further 

R2  -  An  increase  in  the  rework  rate  increases  the  fraction  requiring  rework,  fraction 
discovered,  discovery  rate,  and  Rework  Backlog,  thereby  increasing  the  rework  rate 
further. 


Figure  3.  A  System  Structure  Diagram  of  a  Portion  of  Advanced  Development 

The  full  power  of  system  dynamics  can  be  realized  only  through  formal  simulation  of  the 
system’s  evolution.  Formal  simulation  models  developed  from  conceptual  models  are  sets  of 
nonlinear  differential  equations  simulated  with  difference  equations.  Because  no  closed-form 
solutions  are  known,  system  behaviors  over  time  are  simulated.  The  simulator  uses  initial  or 
current  conditions,  calibration  values  of  constant  parameters,  and  the  difference  equations  to 
calculate  conditions  in  the  nest  time  period.  Although  the  methodology  initially  assumes  that 
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small  changes  over  time  can  be  used  to  describe  systems  (e.g.,  the  continuous  adjustment  of 
resources  toward  demands  for  those  resources);  however,  discrete  changes  (e.g.,  the  release 
of  a  complete  design)  at  specific  dates  (e.g.,  a  scheduled  upgrade  date)  can  also  be  modeled. 

When  applied  to  development  projects,  system  dynamics  focuses  on  how  performance 
evolves  in  response  to  interactions  among  development  strategy  (e.g..  Evolutionary  Acquisition 
versus  traditional  acquisition),  managerial  decision-making  (e.g.,  the  allocation  of  resources), 
and  development  processes  (e.g.,  concurrence).  System  dynamics  is  considered  appropriate  for 
modeling  acquisition  programs  because  of  its  ability  to  explicitly  model  critical  aspects  of 
development  projects  (Ford  &  Sterman,  1998;  Cooper,  1993a,  September;  1993b,  September; 
1993c;  Cooper  &  Mullen,  1993;  Cooper,  1994).  System  dynamics  has  been  successfully  applied 
to  a  variety  of  project  management  issues,  including  prediction/discovery  of  failures  in  project 
fast-track  implementation  (Ford  &  Sterman,  2003b,  September),  poor  schedule  performance 
(Abdel-Hamid,  1988;  Taylor  &  Ford,  2006;  2008),  the  impacts  of  changes  (Rodriguez  & 

Williams,  1998;  Cooper,  1980),  the  planning  of  fast-track  construction  projects  (Pena-Mora  &  Li, 
2001;  Pena-Mora  &  Park,  2001),  construction  innovation  (Park,  Napa  &  Dulaimi,  2004),  change 
management  (Lee,  Pena-Mora  &  Park,  2005;  2006;  Park  &  Pena-Mora,  2003),  resource 
allocation  (Lee  et  al.,  2007),  and  concealing  rework  requirements  on  project  performance  (Ford 
&  Sterman,  2003a,  September).  See  Lyneis  and  Ford  (2007)  for  a  review  and  analysis  of  the 
application  of  system  dynamics  to  projects. 

The  ARCI  Program 

Information  on  the  ARCI  program  was  collected  as  the  basis  for  modeling  the  OA  and 
EA  aspects  of  its  acquisition  process.  In  particular,  differences  between  ARCI  and  traditional 
acquisition  with  an  evolutionary  approach  were  investigated.  Data  was  collected  primarily 
through  a  review  of  Navy  documents  (Johnson,  2007;  Chief  of  Naval  Operations,  2009), 
contractor  program  documents  (Lockheed  Martin,  2003;  2009),  defense  analyst  documents 
(Global  Security,  n.d.),  previous  research  concerning  the  program  (e.g.,  Beaudreau,  2006; 
Johnson,  2004),  and  an  extended  interview  with  Bill  Johnson,  who  developed  and  managed  the 
ARCI  program  (Johnson,  2009).  The  data  collection  focused  on  the  acquisition  (development) 
aspects  of  ARCI.  A  summary  of  the  results  of  that  data  collection  follow. 

Although  it  occurred  within  the  established  DoD  acquisition  processes  of  its  time,  the 
ARCI  program  was  atypical  in  several  important  ways.  The  description  here  focuses  on  the 
program’s  atypical  nature,  as  it  relates  to  the  current  work.  See  Beaudreau  (2006)  and  Johnson 
(2004)  for  additional  program  descriptions.  Three  atypical  aspects  of  the  ARCI  program  in 
particular  generated  the  need  for  and  prompted  the  use  of  a  new  and  different  acquisition 
approach:  1)  the  urgent  operational  need,  2)  tight  constraints  on  funding,  and  3)  an  environment 
of  acquisition  reform. 

An  Urgent  Operational  Need 

In  September  of  1995,  the  Submarine  Sonar  Technology  Panel  reported  a  serious 
reduction  in  acoustic  superiority.  The  reduced  superiority  resulted  in  reductions  in  the  “stand  off” 
distance  between  US  submarines  and  other  vessels  (particularly  other  submarines),  the 
distance  at  which  US  submarines  recognize  other  vessels.  The  standoff  distance  is  determined 
by  the  noise  radiated  from  vessels  and  the  capabilities  of  the  recognizing  ship  through  its  sonar 
systems.  Although  the  radiated  noise  of  other  vessels  had  progressively  reduced  (Figures  4  and 
5),  US  sonar  capabilities  had  not  progressed  in-step.  Improved  sonar  systems  could  recapture 
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the  lost  acoustic  superiority.  Importantly,  the  acoustic  superiority  loss  had  already  occurred  by 
1995,  and  the  need  to  regain  it  was  considered  urgent  by  the  operating  submarine  fleet.  ARCI 
needed  to  develop  solutions  fast.  Figures  4  and  5  are  examples  of  data  used  to  support  these 
findings  and  recommendations. 


1960  1970  1980  1990  2000  2010 


Figure  4.  FSU  (Former  Soviet  Union)/US  Nuclear  Stealth 

(Johnson,  2007) 
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Figure  5.  Diesel  Rated  Noise  Trend 

(Johnson,  2007) 


Based  on  these  findings,  the  Submarine  Sonar  Technology  Panel  recommended  a 
radical  transformation  of  the  approach  to  designing  and  fielding  sonar  systems. 
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Tight  Constraints  on  Funding 


By  1995,  the  Cold  War  was  over  and  funding  for  the  DoD  acquisition  had  reduced 
sharply,  including  Sonar  Development  and  Combat  Control  Development  funding  (Figures  6  and 


□  APB  (A)  Integration  Shortfall 
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Figure  6.  Sonar  Development  Funding 

(Johnson,  2007) 


[□APB(T)  Development  Shortfall 
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Figure  7.  Combat  Control  Development  Funding 

(Johnson,  2007) 
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Traditional  acquisition  approaches,  such  as  the  development  of  unique  systems  for  one 
or  more  sonar  systems,  were  not  available  due  to  the  large  funding  requirements  of  these 
approaches.  ARCI  had  to  develop  solutions  relatively  inexpensively,  at  much  less  cost  than 
required  by  the  traditional  DoD  acquisition  approaches. 

An  Environment  of  Acquisition  Reform 

Although  not  a  characteristic  of  the  ARCI  program  itself,  the  DoD  acquisition  processes 
were  evolving  faster  than  usual  during  the  period  in  which  ARCI  began.  This  had  potentially 
significant  impacts  on  the  program  in  terms  of  allowing  it  more  than  the  usual  amount  of 
freedom  to  pursue  and  develop  innovative  acquisition  perspectives,  methods,  and  tools.  These 
potential  impacts  are  investigated  later  in  the  current  work. 

The  ARCI  Program  Results 

The  ARCI  program  succeeded  in  significantly  improving  US  submarine  sonar  systems 
quickly  and  at  great  savings.  Figures  8  and  9  illustrate  the  demonstrated  performance 
improvements. 
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'  Measured  holding  time  limited  by  the  length  of  recorded  tape. 


Figure  9.  Towed  Array  Processing  Performance-improvement  Trend 

(Johnson,  2007) 


ARCI  performed  quickly.  Phase  I  improvements  were  installed  on  Agusta  in  December 
of  1997,  and  performance  improvements  delivered  18  months  after  the  MDA  decision.  By  the 
eighth  anniversary  of  the  ARCI  MDA  decision  in  June  of  2004,  ARCI  had  installed  on  over  50 
submarines  with  at  least  four  generations  of  hardware  and  software  upgrades.  These  durations 
are  much  shorter  than  those  in  most  comparable  acquisition  programs. 


In  addition  to  improving  sonar  system  performance,  ARCI  generated  large  cost  savings 
(Johnson,  2007)  by  reducing  budget  allocations  across  SCN,  OPN,  O&MN,  RDT&E,  and  MilCon 
by  over  50%  ($7.6  billion  to  $3.6  billion)  when  the  1983-1993  budget  allocations  are  compared 
to  the  1996-2006  allocations.  These  savings  reflect  a  reduction  in  Development  and  Production 
by  a  factor  of  six  and  a  reduction  in  Operating  and  Support  costs  by  a  factor  of  eight.  ARCI  also 
realized  over  $25  million  in  cost  avoidance  for  logistics  support,  including: 

■  Over$1  million  in  technical  manuals, 

■  Over  $2  million  in  direct  vendor  delivery, 

■  Over  $19  million  in  interactive,  multimedia  instruction,  and 

■  $3  million  in  outfitting  spares  reduction. 

In  summary,  ARCI  was  an  extremely  successful  acquisition  program.  A  fundamental 
question  for  learning  how  to  improve  other  acquisition  programs  is  “Why  was  ARCI  so 
successful?”  Several  factors,  internal  to  the  program  and  from  its  environment,  help  explain  this 
success.  Beaudreau  (2006)  focused  on  the  role  of  the  Modular  Open  Systems  Approach 
(MOSA),  now  incorporated  into  the  Navy’s  Open  Architecture  approach,  changing  culture,  and 
systems  engineering  (including  spiral  development,  now  termed  Evolutionary  Acquisition).  The 
current  work  focuses  on  the  dynamic  nature  of  the  ARCI  program  and  what  that  nature  suggests 
about  the  successful  implementation  of  acquisition  programs. 
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Open  Architecture  and  Evolutionary  Acquisition  in  the  ARCI 
Program 

ARCI  was  created  in  the  early  1990s  in  an  unusual  acquisition  environment  that  was 
dominated  by  an  urgent  need  for  significant  improvement  in  active  fleet  capabilities,  very 
constrained  funding,  and  ongoing  acquisition  reforms.  More  specifically,  submarine  sonar 
hardware  and  software  needed  large  improvements  in  performance.  Complete  solutions  were 
not  available  and  ready  for  operational  testing  when  ARCI  began.  The  need  to  develop  solutions 
and  make  improvements  quickly  required  an  evolutionary  approach.  In  addition,  existing 
capabilities  used  legacy  systems,  which  made  repeated  and  fast  changes  difficult  and 
expensive.  Moving  away  from  the  legacy  systems  to  an  Open  Architecture  system  potentially 
provided  the  flexibility  needed  for  frequent  upgrades  as  technologies  developed.  Program 
managers  initially  planned  to  replace  legacy  hardware  with  COTS  (a  central  tenant  of  OA)  to 
take  advantage  of  the  increased  computing  capability  of  hardware  developed  since  the  original 
system  development  and  to  facilitate  future  upgrades.  Reduced  hardware  size  provided  space 
for  the  redesign  of  cabinets,  etc.  so  that  COTS  products  would  meet  military  reliability 
requirements  not  met  by  those  products  “out  of  the  box.”  ARCI  managers  originally  planned  to 
write  middleware  to  link  the  new  hardware  and  legacy  software.  However,  analysis  revealed  that 
rewriting  the  operating  software  in  a  modern  software  platform  (C++)  was  less  expensive  than 
developing  middleware  and  also  provided  opportunities  for  an  Open  Architecture  for  software 
upgrades.  Therefore,  the  Open  Architecture  approach  was  expanded  to  include  software.  Four 
acquisition  iterations  were  initially  designed  (a  central  tenant  of  EA),  each  to  address  a  different 
portion  of  the  sonar  system:  1)  the  towed  array,  2)  the  hull  array, ^  3)  the  spherical  array,  and  4) 
the  high  frequency  arrays.  Each  iteration  used  the  standard  DoD  acquisition  phases  at  the  time 
of  the  program  that  identified  and  specified  requirements,  acquired  technologies,  designed  and 
developed  products,  and  integrated  those  solutions  into  ships. 

As  described  so  far,  ARCI  was  a  straightforward  (albeit  challenging)  integration  of  Open 
Architecture  and  Evolutionary  Acquisition.  However,  the  ARCI  program  included  some  important 
features  that  distinguish  it  from  known  descriptions  of  the  implementation  of  open  systems  and 
Evolutionary  Acquisition.  First,  consider  the  dynamic  nature  of  the  need  (evolving  threats)  and 
solutions  (technology  evolution).  As  hardware  and  software  technologies  improved  and  threats 
evolved,  additional  ARCI  iterations  would  be  needed.  Improvements  would  be  needed  on  an 
almost  continuous  basis  to  adequately  improve  fleet  performance.  Therefore,  ARCI  needed  to 
be  able  to  generate  many  repeatable  capability  upgrade  iterations.  This  required  ARCI  to 
develop  a  process  that  integrated  continuous  processes  with  phased  development.  Open 
Architecture,  and  Evolutionary  Acquisition.  This  was  done  partially  by  setting  frequent  upgrade 
release  dates  and  not  letting  those  dates  slip.  The  first  iteration  was  released  18  months  after 
the  identification  of  initial  requirements,  with  subsequent  upgrades  every  12  months.  This  is 
much  more  frequent  than  the  common  DoD  practice.  The  frequent  integration  of  improvements 
was  possible  only  by  utilizing  many  previously  developed  technologies  and  solutions  from  a 
variety  of  sources  (e.g.,  ONR,  small  businesses,  academics).  “Leverage,  leverage,  leverage” 
was  a  mantra  in  ARCI  that  referred  to  the  program’s  emphasis  on  the  use  of  existing 
technologies  and  solutions. 


^  Some  towed  array  upgrades  were  included  in  some  of  the  second  (hull  array)  iterations  to  respond  to 
the  fleet’s  overwhelming  support  based  on  the  results  of  initial  towed  array  improvement  results  and  the 
fleet’s  urgent  need  for  improvement. 
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ARCI  completed  frequent  upgrades  through  a  second  important  difference  between 
ARCI  and  other  OA  and  EA  programs  that  is  related  to  the  relationship  of  requirements, 
technologies,  products,  and  implementation  to  specific  acquisition  iterations.  Traditional  DoD 
acquisition  (including  traditional  EA)  strongly  link  specific  requirements  to  specific  development 
blocks  at  the  start  of  the  block.  Tests  for  specific  blocks  can  be  failed  if  the  requirements  linked 
to  that  block  are  not  met  and  development  is  slowed  to  be  sure  that  promised  requirements  are 
included.^  Strongly  linking  requirements  to  blocks  before  solutions  have  been  developed 
requires  a  flexible  schedule — in  case  of  development  problems — lots  of  money  to  speed 
development,  or  both.  ARCI  had  little  flexibility  of  time  or  money,  so  it  made  requirements 
flexible  to  meet  iteration  deadlines  (i.e.,  the  commitments  to  upgrade  at  specific  intervals)  and 
control  costs.  This  was  done  with  a  combination  of  a  deviation  from  the  traditional  acquisition 
process  and  the  use  of  a  different  conceptualization  and  utilization  of  several  acquisition 
processes.  ARCI  delayed  the  selection  of  technologies  and  products  to  be  included  in  each 
iteration  until  as  late  as  possible  (typically,  about  six  months  before  delivery)  and  only  included 
(at  the  program  manager’s  discretion)  those  improvements  for  which  developed  technologies 
and  solutions  were  available  and  in-hand.  Requirements  for  which  solutions  were  not  yet 
available  were  delayed  until  solutions  had  been  developed.  ARCI  is  distinguished  from  many 
other  DoD  programs  by  its  ability  to  locate  the  authority  to  include  or  delay  meeting 
requirements  with  the  program  managers.  According  to  the  program  manager,  this  was 
accepted  by  the  fleet  largely  because  the  frequent  iterations  provided  an  opportunity  for  delays 
in  meeting  requirements  to  be  relatively  short,  and  solutions  were  being  developed  relatively 
rapidly. 


ARCI  managers  also  adopted  a  fundamentally  different  mental  model  of  the  acquisition 
process  than  was  described  in  the  DoD  policy  at  the  time  of  the  program  (e.g.,  5000.1)  and 
extended  concepts  that  are  described  in  current  policy  (USD  (AT&L),  2003b,  May  12,  sections  1 
and  2,  pp.  12-13).  Current  policy  describes  sequential  acquisition  phases  (Materiel  Solution 
Analysis,  Technology  Development,  and  Engineering  and  Manufacturing  Development)  that  are 
repeated  after  requirements  are  developed,  with  continuous  technology  development  and 
maturation  (USD  (AT&L),  2003b,  May  12,  Figure  2).  In  contrast,  ARCI  used  continuous 
requirements  development,  technology  development,  and  advanced  development.  Only  the  six- 
month  implementation  phases  (analogous  to  Manufacturing  Development)  were  viewed  as 
specific  to  individual  upgrades.  This,  and  the  Open  Architecture  approach  to  solutions,  required 
ARCI  to  aggressively  pursue  and  actively  manage  and  coordinate  continuous  and  parallel 
requirements  revision,  technology  identification  and  development,  and  product  development. 
This  approach  (three  continuous  processes  and  one  iteration-based  phase)  is  fundamentally 
different  than  traditional  acquisition  (all  iteration-based  phases)  or  current  policy  (one 
continuous  process  and  several  iteration-based  phases).  This  approach  also  required  a  different 
set  of  government  and  contractor  skills  and  relationships. 

ARCI  changed  important  relationships  among  program  participants.  The  prime 
contractor  was  forced  to  take  a  role  of  primarily  providing  coordination  but  not  generating 
solutions.  This  was  to  prevent  solution  bias  in  choosing  technologies  and  products  for  inclusion 
in  upgrades.  Solutions  were  developed  by  multiple  and  diverse  organizations  (e.g.,  academia, 
ONR,  small  businesses)  and  chosen  based  on  transparent  assessments  by  an  objective  team 


^  This  may  be  part  of  why  traditional  EA  is  difficult  to  plan.  Program  managers  must  successfully  predict 
which  requirements  will  be  filled  through  future  technology  development,  product  design,  and 
implementation  when  they  commit  to  meet  specific  requirements  for  specific  development  blocks,  often 
long  before  that  technology  and  product  development  has  occurred  or  can  be  reliably  forecasted. 
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of  experts.  This  successfully  prevented  purposeful  or  accidental  sole-source  acquisition  by 
providing  suppliers  that  were  not  awarded  contracts  with  realistic  opportunities  to  fairly  compete 
and  potentially  win  future  ARCI  work.  These  changes  required  several  atypical  program 
management  skills. 

Modeling  the  ARCI  Program 

The  simulation  model  used  here  is  based  on  a  previously  developed  formal  (i.e., 
computer  simulation)  system  dynamics  model  of  a  DoD  acquisition  project  using  Evolutionary 
Acquisition  and  some  aspects  of  open  systems.  The  model  is  purposefully  simple  relative  to 
actual  practice  to  expose  the  relevant  relationships,  with  a  focus  on  the  open  systems  and 
Evolutionary  Acquisition  aspects.  Therefore,  although  many  development  processes  and 
features  of  program  participants  interact  to  determine  program  performance,  only  those  features 
that  describe  the  critical  evolutionary.  Open  Architecture,  and  ARCI-specific  nature  of  the 
program  are  included.  For  example,  the  model  assumes  that  resource  productivities  are  fixed, 
that  work  backlogs  are  available  for  development,  and  that  work  packages  are  completed  in 
accordance  with  schedule  requirements  (i.e.,  work  packages  on  the  critical  path  are  completed 
first)  but  does  not  identify  specific  critical-path  work  packages.  The  literature  cited  above 
investigates  the  impacts  of  these  and  other  factors  influencing  program  performance.  The  model 
generates  complex  and  realistic  behavior  patterns  despite  its  relative  simplicity  when  compared 
to  the  actual  DoD  acquisition  programs.  A  brief  description  of  the  conceptual  model  that  was 
used  as  the  basis  for  the  formal  model  provides  a  foundation  for  describing  the  current  model  of 
ARCI.  See  Ford  and  Dillard  (2008)  for  a  detailed  description  of  the  previous  model. 

A  Conceptual  Model  of  an  Evolutionary  Acquisition  Program 

The  model  structure  reflects  the  structure  of  development  work  moving  through  the 
separate  development  blocks  of  an  acquisition  project.  In  the  model,  four  types  of  workflow 
through  each  block  of  an  acquisition  project:  requirements,  technologies,  product  component 
designs,  and  manufactured  products.  Each  type  of  work  flows  through  a  development  phase 
that  completes  a  critical  aspect  of  the  project:  1)  develop  requirements,  2)  develop  technologies, 
3)  design  product  components  (advanced  development),  and  4)  manufacture  products.  The 
exception  is  requirements,  which  also  measures  progress  through  the  final  phase,  5)  conduct 
user  product  testing.  Figure  10  shows  development  phases  and  information  flows  in  a  single 
block. 
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Figure  10.  Information  Flows  in  a  Single-block  Acquisition  Project 

(Ford  &  Dillard,  2008) 

In  Figure  10,  arrows  between  phases  indicate  primary  information  flows.  The  start  of  all 
phases  (except  the  development  of  requirements)  is  constrained  by  the  completion  of  previous 
(“upstream”)  phases.  These  constraints  are  relaxed  in  the  ARCI  model  to  reflect  continuous 
development  phases.  In  the  previous  model,  the  completion  of  some  requirements  allows  for  the 
start  of  technology  development,  reflecting  the  concurrent  nature  of  this  portion  of  acquisition. 
Both  requirements  development  and  technology  development  must  be  completed  for  advanced 
development  to  begin.  The  completion  of  advanced  development  allows  manufacturing  to  begin. 
When  some  products  have  been  manufactured,  they  are  shipped  to  users  for  readiness  testing. 
Figure  10  also  identifies  the  five  major  reviews  within  a  single  acquisition  block  (A,  B,  Design 
Readiness  Review,  C,  and  Full-rate  Production)  at  their  approximate  times  during  a  project. 

Each  of  the  five  phases  in  a  development  block  (shown  in  Figure  10)  are  modeled  with 
the  workflows  through  the  phase  as  a  value  chain  of  alternating  backlogs  and  development 
activities  with  two  types  of  rework  cycle  (within  phases  and  between  phases).  The  value  chain  is 
described  with  the  boxes  and  pipes  and  with  valves  along  the  bottom  of  Figure  11.  The  value 
chain  passes  from  the  Initial  Completion  Backlog,  through  the  Initial  Completion  Rate,  into  the 
Quality  Assurance  Backlog,  through  the  Approval  Rate,  into  the  stock  of  Work  Approved,  and 
through  the  Release  Rate  to  the  accumulation  of  Work  Finished  and  Released.  Rework  cycles 
are  inherent  in  development  projects  and  have  been  modeled  and  used  extensively  to  explain 
and  improve  project  management  (Lyneis,  Cooper,  &  Els,  2001;  Ford  &  Sterman,  1998;  Cooper 
&  Mullen,  1993;  Cooper,  1980;  1993a,  February;  1993b,  February;  1993c;  1994;  Taylor  &  Ford, 
2006;  2008).  The  scope  of  work  is  measured  with  the  number  of  equal-sized  work  packages 
that  must  be  completed  in  a  development  phase. 
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Figure  11.  Work  Backlogs  and  Flows  through  a  Development  Phase 

For  most  phases  in  most  blocks,  all  work  starts  in  the  backlog^  of  work  needing  to  be 
initially  completed  (“Initial  Completion  Backlog”  box  at  the  bottom  of  Figure  1 1 ).  The  ARCI 
project  includes  an  exception,  which  will  be  described  later.  As  work  is  first  completed,  it  enters 
the  stock  of  work  needing  quality  assurance  (QA).  Quality  assurance  could  take  many  forms, 
including  reviews  of  designs  by  senior  engineers,  prototype  building  and  testing,  and  the 
inspection  of  work.  Work  needing  quality  assurance  accumulates  in  a  Quality  Assurance 
Backlog  (the  box  in  the  middle  of  Figure  11).  If  work  passes  QA  (either  because  it  is  correct  or 
the  need  for  changes  is  not  detected),  it  is  approved  and  adds  to  the  stock  of  Work  Approved. 
When  sufficient  work  has  been  approved,  a  package  is  released,  adding  to  the  stock  of  Work 
Finished  and  Released  to  other  phases  or  users.  The  release  package  size  is  a  management 
decision,  often  based  on  the  characteristics  of  the  phase.  For  example,  in  semiconductor 
development,  the  vast  majority  of  the  design  code  must  be  completed  prior  to  release  for  a 
prototype  build  since  almost  all  of  the  code  is  needed  to  design  the  masks.  In  other 
development  settings,  managers  have  broad  discretion  in  setting  release  package  sizes. 

In  rework  cycles,  between-phases  work  that  is  found  to  require  changes  moves  into  a 
stock  of  tasks  that  require  changes  that  must  be  resolved  through  coordination  with  the  phase 
responsible  for  the  problem  (“Coordination  Backlog”).  Classic  examples  include  designers 
working  with  users  to  refine  ambiguous  or  infeasible  requirements  or  manufacturing  engineers 
meeting  with  product  designers  to  explain  why  parts  can’t  be  built  as  specified  in  the  drawings. 
After  coordination  resolves  the  disputed  issues,  these  tasks  move  to  the  stock  of  work  known  to 
need  rework  (“Known  Rework  Backlog”)  and  are  subsequently  reworked  and  returned  to  quality 
assurance  for  re-inspection,  testing,  etc. 

Since  quality  assurance  is  imperfect,  some  tasks  requiring  rework  can  be  missed  and 
erroneously  approved  and  released.  These  rework  requirements  may  be  discovered  later  by 
another  work  phase.  We  assume  that  all  defects  are  discovered  in  final  product  testing  by  users. 
When  the  phase  that  discovers  the  problem  reports  it,  the  generating  phase  is  notified,  and  the 
affected  tasks  are  moved  from  the  stock  of  work  considered  finished  to  the  coordination  backlog 


®  Because  the  flows  of  development  activities  reflect  the  completion  of  the  activity,  the  backlogs,  as  used 
here,  include  work  in  progress  as  well  as  work  on  which  development  has  not  yet  been  started. 
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and  then  eventually  reworked.  For  example,  a  test  phase  may  discover  a  short  circuit  across 
two  layers  in  a  prototype  chip.  If  the  error  is  traced  to  the  design,  test  engineers  must  notify  the 
designers  and  work  with  them  to  specify  the  location  and  characteristics  of  the  short  circuit.  The 
designers  must  then  rework,  re-check  and  re-release  the  design,  followed  by  changes  in  layout, 
tape-out,  masking,  and  prototype  fabrication. 

The  previous  model  of  Open  Architecture  and  Evolutionary  Acquisition  simulated  the 
movement  of  work  through  an  acquisition  program.  That  model  linked  all  five  phases  to  specific 
iterations,  which  were  completed  at  different  intervals  (Figure  10).  Figure  12  depicts  an 
acquisition  project  with  multiple  iterations  or  blocks.  The  first  block  is  the  same  as  Figure  10 
above.  Subsequent  blocks  have  the  same  basic  information  flow,  but  can  also  be  delayed  by 
the  completion  of  phases  in  previous  blocks  or  constrained  by  the  lack  of  progress  in  their  own 
block. 


Time  Periods 

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30 


Figure  12.  Information  Flows  in  a  Three-block  Acquisition  Project 

(Ford  &  Dillard,  2008) 

Modeling  Open  Systems  in  an  Evoiutionary  Acquisition  Program 

The  previous  simulation  model  reflected  some  important  aspects  of  open  systems  by 
changing  model  parameters  to  reflect  impacts  of  open  systems  suggested  by  the  literature.  As 
an  example.  Table  1  describes  some  of  the  open  systems  impacts  derived  from  Meyers  and 
Oberndorf  (2001 )  that  were  incorporated  into  the  model. 


DEFENSE  ACQUISITION  IN  TRANSITION 


-223- 


Table  1.  Impacts  of  Open  Systems  on  Evolutionary  Acquisition  Due  to  Changes 
Suggested  by  Meyers  and  Oberndorf  (2001) 

(Ford  &  Dillard,  2008) 


Change  Required  by 
Open  Systems 

1 )  Build  standards  &  COTS  for 
program  use 

2)  Build  high-level  model  with  open 
systems 

3)  Document  use  of  OS 

4)  Coordinate  standards 

5)  Implement  OS 

6)  Integrate  components 


Impact  on  Evolutionary  Acquisition  Processes 

Increases  Requirements  scope  in  Block  1 
Increases  Technology  Development  scope  in  Block  1 
Increases  Technology  Development  scope  in  Block  1 

Increases  Technology  Development  scope  in  all  blocks 
Increases  scope  of  all  phases  in  all  blocks 
Decreases  Advanced  Development  scope  in  all  blocks 
Fewer  Advanced  Development  design  problems  in  all  blocks 
More  Advanced  Development  integration  problems  in  all  blocks 
More  Manufacturing  integration  problems  in  all  blocks 


Model  Changes  to  Reflect  the  ARCI  Program 

The  structure  of  the  simulation  model  of  a  traditional  acquisition  program  that  adopts 
Open  Architecture  and  Evolutionary  Acquisition  approaches  was  changed  to  better  reflect  the 
ARCI  program.  The  primary  changes  are: 

■  Rename  “Advanced  Development”  as  “Design”  to  reflect  the  broader  acquisition 
approach  to  this  phase  in  ARCI  that  often  adopted  existing  solutions  instead  of 
developing  new  solutions  such  as  is  often  done  in  many  traditional  programs. 

■  Rename  the  “Manufacturing”  phase  to  the  “Integration”  phase  to  reflect  the  nature  of 
this  activity  in  ARCI. 

■  Model  the  Requirements,  Technology,  and  Design  phases  as  a  single,  continuous 
development  activity  that  occurs  throughout  the  program. 

■  Begin  the  program  with  a  set  of  initially  developed  requirements  to  be  addressed  but 
no  inflow  of  new  requirements.  This  reflects  the  conditions  at  the  beginning  of  the 
program  and  the  nature  of  the  needs  that  the  program  was  addressing  (i.e.,  largely 
understood  and  described). 

■  Model  the  Integration  activity  as  separate  phases  (as  in  the  previous  model),  but 
start  those  phases  at  specific  times  (6  months  before  release),  and  end  them  at 
specific  Integration  release  dates. 

■  Fix  Integration  release  dates  at  1 .5  years  after  the  program  start  (MDA)  for  the  first 
release  and  then  annually  thereafter  (i.e.,  at  weeks  78,  130,  182,  and  234). 

■  Disaggregate  supplier-resource  types  into  three  types,  reflecting  those  addressing 
technology  acquisition,  design,  and  implementation.  The  resources  include  several 
types  of  suppliers:  contractors,  CNR,  government  labs,  and  academic  agencies. 
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Resources-for-requirements  was  not  separately  modeled  because  the  requirements 
were  largely  already  developed  at  the  start  of  the  program,  and  resources  for 
checking  and  revising  requirements  was  not  considered  by  the  program  manager  to 
constrain  program  progress. 

■  Disaggregate  government  program-management  resources  into  three  types, 
reflecting  the  same  three  types  of  resources  as  supplier  modeling:  technology, 
design,  and  integration  work. 

Little  specific  data  was  available  for  model  parameter  estimates.  Therefore,  the  ARCI 
model  was  calibrated  using  data  collected  through  the  interview  with  the  program  manager  and 
with  modeler  estimates.  Figure  13  shows  typical  simulated  behavior  patterns  of  the  ARCI 
program. 


Time  (weeks) 


Work  Approved[RequireiTients,Iterl] :  ARC! — ^ 
Work  Approved[Technology,Iterl]  ;  ARCI 
Work  Approved[Design,lterl  ] :  ARCI  - 
Integration  work  approved  ;  ARCI^^^^^^^^“ 


—  work  packages 

—  work  packages 

4—  work  packages 

work  packages 


Figure  13.  Approved  Work  in  the  Simulated  ARCI  Program 

The  vertical  axis  in  Figure  13  is  work  packages,  as  described  above.  Figure  13  reflects 
the  critical  behavior  patterns  that  describe  the  ARCI  program.  Work  for  each  upgrade 
progresses  first  through  the  checking  and  revision  (as  required)  of  requirements  (blue  line  #1  in 
Figure  13),  subsequent  acquisition  of  technologies  to  fulfill  those  requirements  (red  line  #2  in 
Figure  13),  and  design  of  upgrade  solutions  using  those  technologies  (green  line  #3  in  Figure 
13).  As  in  the  ARCI  program,  these  continue  throughout  all  upgrades  (weeks  0-250  in  Figure 
13).  But  the  accumulation  of  mature-enough  requirements,  technologies,  and  designs  for  each 
upgrade  are  collected  at  weeks  52,  104,  and  156  (6  months  before  each  release)  to  initiate  the 
Integration  phase  for  the  upgrade.  The  four  Integration  phases  (grey  line  #4  in  Figure  13)  each 
last  six  months  and  end  at  the  release  of  each  upgrade  package  to  the  fleet  for  operational 
testing  and  use.  Consistent  with  ACRI,  the  revision  of  requirements,  acquisition  of  technologies. 
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and  design  of  solutions  does  not  stop  during  integration  but  continues,  as  show  in  Figure  13  by 
the  overlapping  of  the  progress  rate  lines  during  the  Integration  phases. 

The  ARCI  model  was  tested  for  its  usefulness  for  investigating  implementation  issues. 
Standard  model  tests  as  described  by  Sterman  (2000)  were  used,  including  testing  both  the 
model  structure  and  behavior.  The  model  is  based  on  previously  developed  system  dynamics 
models  of  product  development  in  several  industries  that  have  been  developed  and  tested  over 
several  decades,  as  described  and  referenced  above.  Model  structure  was  tested  for  similarity 
to  the  structure  of  the  actual  system  through  one-to-one  linking  of  model  components  and 
specific  parts  of  the  system  structure  and  units-consistency  checks.  Models  were  tested  for  their 
ability  to  generate  “the  right  behavior  patterns  for  the  right  reasons”  (i.e.,  for  the  same  reasons 
as  in  the  actual  system)  using  extreme-conditions  testing  and  the  comparison  of  simulated 
behavior  patterns  with  an  understanding  of  the  behavior  of  the  actual  and  similar  systems.  In 
extreme-conditions  testing,  one  or  more  model  parameter  values  are  set  to  represent  extreme 
conditions,  which  the  modeler  can  use  to  predict  correct  model  behavior.  For  example,  the 
extreme  condition  of  no  resources  should  generate  a  program  with  no  progress.  The  ARCI 
model  generated  reasonable  behavior  over  a  wide  range  of  parameter  values.  The  model 
behavior  is  similar  to  the  described  project  behaviors,  also  supporting  the  model’s  ability  to 
reflect  the  relevant  portions  of  the  ARCI  program.  Based  on  these  tests,  the  model  was 
considered  useful  for  investigating  RCIP  implementation  issues. 

Modeling  RCIP 

The  Rapid  Capability  Insertion  Process  (RCIP)  seeks  to  develop  a  process  that  can 
capture  the  types  of  performance  improvements  realized  by  ARCI  in  more  and  larger  acquisition 
programs.  The  upgrading  of  AEGIS  and  its  preparation  for  net-centric  warfare  is  a  potential 
application  of  RCIP.  RCIP  is  based  on  the  ARCI  program  and  includes  its  core  concepts  and 
changes  from  most  traditional  acquisition  projects,  including  those  that  adopt  the  Open 
Architecture  and  Evolutionary  Acquisition  approaches.  However,  based  on  an  interview  with  one 
of  the  RCIP  developers  (2009),  there  will  be  differences  between  ARCI  and  RCIP,  primarily: 

■  RCIP  will  be  applied  to  larger  acquisition  efforts  (e.g.,  AEGIS); 

■  After  an  initial  start-up  phase,  RCIP  will  receive  and  develop  a  continuous  stream  of 
new  requirements  instead  of  having  a  fixed  set  of  established  requirements  in  place, 
as  ACRI  had; 

■  RCIP  is  initially  planned  to  release  upgrades  to  the  fleet  every  two  years,  thereby 
adopting  a  cycle  that  is  twice  as  long  as  that  used  in  ARCI;  and 

■  RCIP  is  planned  to  use  12-month  integration  periods,  twice  as  long  as  those  in  ARCI. 

These  differences  were  integrated  into  the  simulation  model  to  provide  an  estimate  of 
the  potential  of  the  RCIP  approach.  This  represents  a  simple  (and  simplistic,  as  will  be 
explained)  scaling  of  the  ACRI  approach  to  RCIP.  Figure  14  shows  RCIP’s  potential 
performance.  Steady-state  output  exceeds  the  ARCI’s  average  output,  although  ARCI’s 
transitional  (versus  steady-state)  nature  and  model  calibration  preclude  useful  direct 
comparisons. 
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Figure  14.  Simulated  RCIP  Program  Behavior 

Figure  14  includes  the  fundamental,  desired  behavior  of  RCIP,  a  basically  continuous 
process  of  requirements  development  upgrades  (after  an  initial  start-up  phase).  While  useful  as 
a  benchmark  for  the  current  work,  important  risks  must  be  addressed  to  better  reflect  the  RCIP 
approach. 

The  RCIP  Implementation  Risks 

A  simple  scaling-up  of  the  ARCI  program  into  an  RCIP  program  will  not  capture  the 
potential  performance  (especially  considering  that  the  model  above  is  simplistic)  because  it 
ignores  important  implementation  risks  that  can  degrade  RCIP  performance  when  compared  to 
its  potential.  In  addition  to  the  changes  from  ARCI  to  RCIP  listed  above,  several  implementation 
challenges  pose  risks  that  may  affect  RCIP,  including:  1),  an  increased  pool  of  suppliers  due  to 
increased  scale,  2)  a  reduced  number  of  off-the-shelf  technologies  and  designs  available  for 
use,  resulting  in  a  need  for  more  new  development,  and  3)  increased  systems  that  solutions 
must  be  integrated  across.  Table  2  contrasts  the  three  acquisition  programs  to  highlight  their 
differences  and  identify  some  RCIP  implementation  risks. 
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Table  2.  Contrasts  among  Traditional  Phased,  ARCI,  and  RCIP  Acquisition  Programs 


Acquisition  Feature 

Phased 

Program  with 

OA  &  EA 

ARCi 

Program 

RCiP 

Programs 

fvs.  ARCn 

Deveiopment 
processes  (Req.,  Tech, 
AdvDev) 

Repeated  separate 
phases 

Primarily  continuous 
processes,  known 
requirements 

Continuous  processes 

with  continuous  infiow 

of  reauirements 

innovation  sources 

Primarily  through 
Prime  Contractor 

Primarily  Off-the-shelf 
solutions 

Mix  of  new  deveiopment 

&  off-the-sheif  More 

new  deveiopment 

Product  System 
Moduiarity 

Often  integrated 
across  phases  & 
development  blocks 

Primarily  separate 
systems  (towed,  hull, 
spherical,  high 
frequency) 

More  svstems  and 

svstem  interactions. 

More  inter-svstem 

intearation  reauired 

Govt./Suppiier 

Reiationships 

Prime  contractor 

“Prime”  coordinator  & 
multiple  solution 
suppliers 

Laraer  soiution  suppiier 

pool 

Primary  Locus  of 
Performance  Fiexibiiity 

Cost,  Schedule 

Scope 

Scope  with  possible 

flexibilitv  in  cost 

The  Primary  Locus  of  Program  Flexibility  (the  last  row  in  Table  2)  describes  a  generic 
model  of  program  management  that  can  partially  explain  the  ARCI  success  and  facilitate  the 
design  and  management  of  RCIP  programs.  The  model  describes  how  program  management 
handles,  in  practice,  the  ubiquitous  circumstances  of  having  inadequate  resources  (broadly 
defined)  to  meet  all  performance  targets  (e.g.,  cost  <=  budget,  completion  date  <=  deadline, 
capabilities  >=  warfighter  needs).  In  these  circumstances,  program  management  is  forced  to 
select  one  or  more  performance  dimensions  that  will  not  meet  targets  and  project  by  how  much 
they  will  underperform.  The  dimension  or  dimensions  that  are  chosen  is  the  Primary  Locus  of 
Program  Performance  Flexibility.  A  common  saying  among  commercial  contractors  (although 
perhaps  not  said  to  their  clients)  that  captures  the  essence  of  this  model  is  “Fast,  cheap,  good. 
Pick  two.”  Table  2  identifies  the  Primary  Locus  of  Performance  Flexibility  as  a  significant 
difference  between  traditional  programs  with  Open  Architecture  and  Evolutionary  Acquisition 
and  programs  adopting  the  ARCI/RCIP  approach.  In  the  former,  performance  flexibility  is 
primarily  located  in  the  cost  and  schedule  dimensions.  In  contrast,  in  the  ARCI  program,  it  was 
in  the  scope  included  in  the  current  upgrade.  In  the  RCIP  approach,  it  is  expected  to  remain  in 
the  scope  dimension,  with  the  possibility  that  cost  may  also  provide  some  flexibility. 

The  RCIP’s  expected  implementation  risks  were  integrated  into  the  simulation  model. 
Specifically: 

■  Increased  scope  is  expected  to  attract  increased  oversight  and,  therefore,  reduce 
productivity  due  to  the  use  of  resources  (primarily  labor)  in  the  preparations  for 
reviews,  etc.  (20%  reduction  estimated). 

■  Existing  inventories  of  requirements,  off-the-shelf  technologies,  and  off-the-shelf 
designs  were  reduced  by  50%  to  reflect  the  need  for  more  new  development.  This 
will  require  their  initial  development  in  addition  to  the  testing  and  revisions  included  in 
the  ARCI  model. 
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■  Increased  new  development  will  also  require  more  integration  effort  than  off-the- 
shelf  solutions,  which  have  already  been  partially  developed  for  integration  upon 
adoption.  Therefore,  the  amount  of  integration  work  was  increased  by  25%. 

■  Increased  new  development  will  also  make  integration  more  difficult  than  off-the- 
shelf  solutions,  which  have  been  partially  tested  for  integration  upon  adoption. 
Therefore,  the  amount  of  iteration  required  in  the  integration  phases  was  increased 
by  25%. 

Figure  15  shows  the  simulated  RCIP  program  with  implementation  risks.  The  program 
retains  its  fundamental  behavior  pattern  of  a  primarily  continuous  upgrade  process. 
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Figure  15.  Simulated  RCIP  with  Implementation  Challenges 

Implications  of  Implementation  Risks  for  RCIP  Success 

The  work  completed  and  released  to  the  fleet  when  RCIP  implementation  risks  are 
considered  (Figure  15)  is  significantly  less  than  the  potential  (Figure  14).  Figure  16  illustrates 
this  difference  (about  14%  in  the  simulated  program)  by  accumulating  the  Integration  phase 
work  released  across  four  upgrades,  without  (blue  line  #1)  and  with  (red  line  #2)  implementation 
risks  included.  RCIP  implementation  risks  must  be  addressed  to  capture  the  full  potential  of  the 
ARCI  approach  in  RCIP. 
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Figure  16.  Cumulative  RCIP  Performance  without  and  with 
Implementation  Issues 

Another  RCIP  implementation  risk  is  program  management  burnout.  The  ACRI  program 
manager  specifically  identified  the  potential  of  burnout  in  his  program  management  team  due  to 
the  repeated,  intense  Integration  phases.  To  investigate  the  possibility  and  severity  of  this  risk  to 
RCIP  implementation,  the  total  required  (but  not  necessarily  provided)  government  program- 
management  workforce  size  was  simulated  for  the  ARCI  program,  RCIP  without  implementation 
risks,  and  RCIP  with  implementation  risks  (Figure  17).  Figure  17  clearly  shows  the  spikes  in 
demand  for  program  management  during  the  Integration  phases  for  all  three  simulations.  Notice 
that  the  peaks  are  significantly  higher  for  both  RCIP  simulations  than  for  the  ACRI  simulation. 
This  suggests  that  the  burnout  risk  will  be  larger  for  RCIP  than  it  was  for  ACRI.  Successfully 
Implementing  a  sustainable  RCIP  program  will  require  a  method  to  address  potential  burnout  of 
the  government  program-management  workforce. 
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Figure  17.  Simulated  Total  Required  Government  Program-management 
Workforce:  ARCl,  RCIP  without  and  with  Implementation  Risks 

Managing  RCIP  Implementation  Risks 

The  RCIP’s  implementation  risks  can  be  managed  through  the  careful  design  of  its 
processes,  organizations,  and  their  interactions.  Specific  recommendations  based  on  the  ARCl 
program  and  the  modeling  and  analysis  discussed  above  are  described  in  Table  3. 


DEFENSE  ACQUISITION  IN  TRANSITION 


-231  - 


Table  3.  Managing  RCIP  Implementation  Risks 


Acquisition 

Feature 

ARCI 

Program 

RCIP 

Programs 

fvs.  ARCn 

RCIP 

Implementation  Risk 

Management 

Deveiopment 

processes 

Primarily 

continuous 

processes, 

known 

requirements 

Continuous 
processes  with 
continuous  inflow  of 
requirements 

Standardize  continuous  processes 

and  add  door  for  sustainabiiitv 

innovation 

sources 

Primarily  Off-the- 
shelf  solutions 

Mix  of  new 
development  &  off- 
the-shelf.  More  new 
development 

1 )  Adapt  continuous 
processes  into  a  mixture  of  off- 

the-sheif  &  new  deveiopment 

soiutions 

2)  Impiement  EA  “oniv- 
mature-enouoh”  strateav 

Product 

System 

Moduiarity 

Primarily 

separate  systems 
(towed,  hull, 
spherical,  high 
frequency) 

More  systems  and 
system 

interactions.  More 
inter-system 
integration  required 

Operationaiize  moduiar 
confiauration  manaaement  for 
iarae-scaie  acauisition  with  focus  on 

inteoration 

Government  / 

Suppiier 

Relationships 

“Prime” 
coordinator  & 
multiple-solution 
suppliers 

Larger-solution 
supplier  pool 

Formaiize  open,  transparent, 
obiective,  &  repetitive  competition 

processes  and  oraanizations 

Primary  Locus 
of  Performance 
Flexibility 

Scope 

Scope  with 
possible  flexibility  in 
cost 

1)  Improve  user-acauisition 
coordination  to  facilitate  scope 

flexibilitv 

2)  Operationalize  ARCI 
manaaement  of  solution 

acauisition  to  make  RCIP 
responsive  to  warfiahter  priorities 

Conclusions 

The  Acoustic  Rapid  COTS  Insertion  (ARCI)  program  was  studied  as  the  basis  for 
modeling  the  planned  Rapid  Capability  Insertion  Process  (RCIP)  approach  for  continuous, 
reduced-cost  upgrading  of  warfighting  assets.  ARCI  used  atypical  methods  in  the  face  of 
atypical  program  requirements  and  conditions.  ACRI  was  very  successful  in  improving 
performance  quickly  for  reduced  costs.  A  previously  developed  acquisition  program  model  was 
adapted  to  reflect  ARCI  and  used  for  model  validation.  This  model  was  then  changed  to  reflect 
the  basic  conditions  expected  in  RCIP  programs.  The  model  demonstrated  the  potential  of  RCIP 
to  improve  program  performance.  However,  implementation  risks  were  identified  that  may 
degrade  potential  performance,  including  increased  oversight,  the  use  of  more  new 
development,  and  the  resulting  integration  scope  and  risk.  When  incorporated  into  the  model, 
these  risks  were  shown  to  significantly  decrease  RCIP  performance.  The  means  for 
successfully  managing  the  RCIP  design  based  on  the  ACRI  program  and  RCIP  operations  are 
suggested  for  use  in  addressing  the  identified  implementation  risks 

Based  on  the  work  described  above,  we  conclude  that  RCIP  has  great  potential  to 
improve  acquisition.  But  the  failure  to  identify  and  successfully  address  implementation  risks,  in 
particular,  can  significantly  constrain  RCIP  program  performance.  Special  attention  must  be 
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paid  in  the  design  of  the  RCIP  approach  to  the  differences  between  the  ACRI  program  and  the 
features,  characteristics,  and  environmental  conditions  that  RCIP  programs  will  face.  The  five 
principles,  concepts  and  tools  and  methods  embodied  in  the  Navy’s  Open  Architecture 
approach  to  acquisition  are  likely  to  be  particularly  useful  in  developing  RCIP  and  addressing  its 
implementation  risks.  Many  Open  Architecture  concepts  were  used  successfully  in  the  ACRI 
program,  including  modular  design,  design  disclosure,  interoperability,  lifecycle  affordability,  and 
lots  of  vigorous  (and  vigorously  managed)  competition  to  generate  a  wide  range  of  possible 
solutions  from  many  sources.  Applying  Open  Architecture  required  strong,  assertive, 
government  program  management  but  provided  the  basis  for  extraordinary  success.  Similar 
extraordinary  success  is  possible  in  RCIP  programs  but  will  also  require  a  process  based  on 
Open  Architecture  and  vigorous  and  assertive  management  by  the  government.  By  doing  so, 
RCIP  can  become  an  example  of  effective  and  efficient  acquisition  for  widespread  adoption  to 
many  acquisition  efforts. 
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Acquisition  Chaiienges 


•Fast  evolution  of  threats  and  technologies  -  often 

faster  than  acquisition  programs 

•  Need  acquisition  of  systems  that  are  integrated 

-  Across  system  mission  (e.g.  ISR,  navigation) 

-  Across  platforms  (carriers,  destroyers,  cruisers,  etc.) 

-  Across  capability  improvements  (e.g.  technology  upgrades) 

•  Need  repeatable  capability  upgrade  process 

•  Rapid  Capability  Insertion  Process  (RCIP) 

-  Conceptually  designed , 

-  Needs  better  understanding  of  drivers  of  success  for  implementation 


Designing  and  Managing  Fast 
Evoiving  Acquisition 


•  Open  Architecture  (OA): 

•  Modular  design  and  design  diselosure 

•  Reusable  applieation  software 

•  Interoperable  joint  warfighting  applieations  and  seeure  information 
exehange 

•  Life  eyele  affordability 

•  Eneouraging  eompetition  and  eollaboration  through  development  of 
alternative  solutions  and  sourees 


•  Evolutionary  Acquisition  (EA): 

•  Coneurrent  development  phases 

•  Only  mature-enough  teehnologies 


•  But  successful  OA/EA  programs  have  been  episodic, 
not  standard  practice. 


efense  Acquisition  in  Transition 

i^NNUAL  Acquisition  Research  Symposium 


May  12-14,  2009 
Monterey,  CA 


Research  Questions 


Ql:  How  have  OA  and  EA  been  successfully 
integrated  for  rapid  capability  insertion? 

Q2:  How  can  successful  OA/EA  processes  and 
experiences  be  integrated  into  RCIP? 
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Research  Approach 


1)  Build  simulation  model  of  successful  rapid 
capability  insertion  process  (ARCI  program) 

2)  Change  simulation  model  to  better  reflect  RCIP 

3)  Simulate  RCIP  under  variety  of  program 
characteristics  and  program  environment 
conditions 


4)  Analyze  results  to  better  understand  RCIP 
drivers 
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The  Acoustic  Rapid  COTS  Insertion 
Program  (ARCI)  -  Background  ( 1  of3) 


•  Early  1990s:  Real  and  immediate  reduction  in  submarine 
sonar  advantage 


FSU/US  Nuclear  Stealth 


From  ARCI  -  A  Historical 
Perspective,  Mr.  William 
Johnson,  IWS  7.0 
Deputy  Major  Program 
Manager 

Future  Combat  Systems  Open 
Architecture 


Critical  issue  for  the  operating  fleet  -  needed  improvement  fast! 
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ARC  I  —  Background  (2of3) 


•  Sharp  reduction  in  funding  -  “Build-new"  not  possible  - 
needed  improvement  cheap! 


□  APB  (A)  Integration  Shortfall 

■  A-RCI/APB  Integration 

□  BSY-2  Development 

□  BSY-1  Development 

□  Support  Sonars 

■  AN/BQQ-6 

□  AN/BQQ-5E 

□  AN/BQQ-5D 

■  AN/BQQ-5C 

□  AN/BQQ-5B 
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ARC  I  -  Background  (3of3) 


•  Legacy  processors,  software,  and  work 
stations  were  old  (circa  1970s)  and  custom 
built  -  expensive  and  slow  to  change  - 
needed  a  different  acquisition  process! 
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ARC  I  —  Program  Performance  (1of2) 


•New  upgrades  (“builds”)  every  12 
months  -  no  schedule  slippage 

•  Cost  avoidance  >  $3  billion 
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ARC  I  —  Program  Performance  (2of2 ) 

•  Sonar  capability  improvement 


l'-1/BQQ- 
BaselineQ  - 
Performance 


/ 

7 

is 

A 

TB-23 


I  I 

TB-29 


>  X 
(fl  c 
£ 

< 


kj 


Is 

6-1 


y 


il* 

0-1 


PNB  pbb 

A-RCI  Phase  I 


TB-29  PNB 


Phase  II 


Spherical 

Array 


V 


D  Full  Spectrum 
Processing 

□  TB-29  Array 
Gain 


□ 


□ 


□ 


□ 


Spatial  Vernier 
Processing 

Linear 

Beamforming 

Advantage  Over 
DIMUS 

Computer  Aided 
Detection 

Other  Processing 
Improvements 


IF  Upgrade 


Phase  III  Phase  IV 


efense  Acquisition  in  Transition 

jP^n'nual  Acquisition  Research  Symposium 


May  12-14,  2009 
Monterey,  CA 


Modeling  ARCI: 

A  Traditional  Acquisition  Process 


Time  Periods 

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21 


Develop  Requirements 

Develop  Technologies 

Advanced  Development 

Manufacturing 

User  Product  Testing 

Delays  in  developing  requirements,  technologies,  or  designs  often 
delay  deployment. 
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Modeling  ARCI: 

An  Evolutionary  Acquisition  Process 

Time  Periods 

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30 


•  Revised  EA  project  model  to  reflect  some  important 
characteristics  of  Open  Architecture  (OA):  modularity,  standards 
management,  reduced  component  design,  etc. 
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Modeling  ARCI: 

The  ARCI  Acquisition  Process 


Months  from  Initial  Requirements  Release 

0  3  6  9  12  15  18  21  24  27  30  33  36  39  42  45  48  51  54  57  60 
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•  Select  mature-only  requirements,  technologies,  and  designs  at  ^ ; 


beginning  of  Integration 

•  Delay  solutions  to  next  upgrade  to  not  delay  build  if  required 


ARCI- 

Simulation  Results 


Work  Approved[Requirements.Iterl]  :  ARCI — 

Work  Approved[Technology,Iterl] :  ARCI - 

Work  Approved[Design,Iterl]  :  ARCI  _ 
Integration  work  approved  :  ARCI^^^^^^^^^™ 


-  work  packages 

-  work  packages 

work  packages 


Approved  Requirements,  Technologies,  Design  &  Integration 


^^work  packages 
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Revising  the  Modei  to  Reflect  the 
Rapid  Capability  Insertion  Process  (RCIP) 


•  Increase  scope  to  reflect  larger  programs 

•  Continuous  inflow  of  new  requirements 

•No  existing  inventory  of  requirements  in  steady 
state 

•  Reduced  inventory  of  off-the-shelf  solutions 

•  Capability  upgrades  every  2  years  (vs.  yearly) 

•  Integration  phase  duration  =12  months  (vs.  6 
months) 
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RCIP- 

Opportunities  for  Improved  Performance 


^  Steady  state 
Avg  =  60wp/build 


50  100  150  200  250 
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Approved  Requirements,  Technologies,  Design  &  Integration 
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Work  Approved[Requirements,Iterl] :  RCIP  Opportunity- 

Work  Approved[TechnoIogy,Iterl] :  RCIP  Opportunity - 

Work  Approved[Design,Iterl]  :  RCIP  Opportunity 
Integration  work  approved  :  RCIP  Opportunit)^^^^^^— 


—  work  packages 

—  work  packages 

4^—  work  packages 
work  packages 


ARCI  to  RCIP  - 

Implementation  Challenges 


Acquisition  Program 

Feature 

Phased  Program 

with  OA  &  EA 

ARCI 

Program 

RCIP 

Programs  (vs.  arci) 

Development  processes 

(Requirements,  Technologies, 
Advanced  Development) 

Repeated  separate  phases 

Primarily  continuous 
processes,  known 
requirements 

Continuous  inflow 

of  reauirements 

Innovation  sources 

Primarily  through  Prime 
contractor 

Primarily  Off-the-shelf 
solutions 

Mix  of  new 
development  &  off- 

the-shelf 

Product  System 
Modularity 

Often  integrated  across 
phases  &  development 
blocks 

Primarily  separate 
systems  (towed,  hull, 
spherical,  high  frequency) 

More  svstems 

&  system 

interactions.  More 

inter  -  system 
intesration  reauired 

Govt. /Supplier 
Relationships 

Prime  contractor 

“Prime”  coordinator  & 
multiple  solution 
suppliers 

Larser  solution 

supplier  pool 

Primary  Locus  of 
Performance  Flexibility 

Cost,  Schedule 

Scope 

Scope  with  possible 

flexibility  in  cost 
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RCIP  Implementation  Challenges  - 

Changes  to  the  Simulation  Model 


•  Increase  scope  more  oversight 

-  Reduced  productivity  on  larger  scope  (reduced  20%) 

•  No  existing  inventory  of  requirements  (steady  state) 


•  Reduced  inventory  of  off-the-shelf  solutions 

-  Reduce  techn.  &  Adv  Dev  initially  developed  (50%) 

-  Increased  iteration  in  integration  phases  (increased  25%) 


•  Increased  integration  required 

-  More  integration  scope  (increased  25%/solution) 
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RCIP  Implementation  Challenges 

Simulation  Model  Results 


Work  Approved[Requirements,Iterl]  :  RCIP  ChalleiiM 
Work  Approved[Technology,Iterl]  :  RCIP  Challenge^ 
Work  Approved[Design,Iterl] :  RCIP  Challengea 
Integration  work  approved  :  RCIP  Challenge^^^^^— 


-4- 


-4- 


-4- 


-4- 


-4- 


-  work  packages 

-  work  packages 

work  packages 


^^^work  packages 


Approved  Requirements,  Technologies,  Design  &  Integration 
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RCIP  Implementation  Challenges  - 

The  Burnout  Challenge 


RCIP  will 
require 
significantly 
more 

Government 
Program 
Management 
resources 
due  to 
“bursts”  of 
integration 
work. 


Required  total  Govt  PM  workforce  :  ARCI -  - 1 — o - ^ ^ O ^ — O - ^ — O - ^ — O - ^ — O - ^ O ^ ^ 

Required  total  Govt  PM  workforce  :  RCIP  Opportunity - ^ ^ ^ ^  J  ^ J ^  J — je - ^ ^ — jr -  person 

Required  total  Govt  PM  workforce  :  RCIP  Challenges - ^ - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 -  person 
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Implications  for  Practice 

Addressing  RCIP  Implementation  Challenges 


Acauisition 

Feature 

ARCI 

Proqram 

RCIP 

Proqrams  (vs. 

ARCn 

RCIP 

Implementation  Risk  Manaqement 

Development 

processes 

Primarily  continuous 
processes,  known 
requirements 

Continuous  processes 
with  continuous  inflow 
of  requirements 

1)  Standardize  continuous  processes 

2)  Add  ri2or  for  sustainabilitv 

Innovation  sources 

Primarily  Off-the-shelf 
solutions 

Mix  of  new 

development  &  off-the- 
shelf  More  new 
development 

1)  Adapt  continuous  processes  to  mix  of 

off-the-shelf/new  development 

solutions 

2) Use  “only  -  mature  -  enou2h” strate2V 

Product  System 
Modularity 

Primarily  separate 
systems  (towed,  hull, 
spherical,  high  frequency) 

More  systems  and 
system  interactions. 

More  inter  -  system 
integration  required 

Operationalize  modular  confi2uration 

mana2ement  for  lar2e  scale  acauisition 

with  focus  on  inte2ration 

Government  / 

Supplier 

Relationships 

“Prime”  coordinator  & 
multiple  solution 
suppliers 

Larger  solution  supplier 
pool 

Formalize  open,  transparent,  obiective, 

&  repetitive  competition  processes  and 

or2anizations 

Primary  Locus  of 

Performance 

Flexibility 

Scope 

Scope  with  possible 
flexibility  in  cost 

Improve  user  -  acauisition  coordination 

to  make  RCIP  responsive  to  warfi2hter 

priorities 
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More  Implications  for  Practice 

Designing  RCIP  Implementation 


•  Improved  integrated  organization/process  design 
and  description 

-  Frequent  solution  competitions,  closer  user-acquisition  coordination, 

-  As  operational  as  possible 

•New  supplier  roles 

-  Former  “prime”  in  coordinator-only  role,  not  solution  supplier 

-  Many  and  diverse  solution  suppliers 

•New  Government  Program  Management  skills 

-  Dynamic  management  of  requirements  selection  and  solution 

acquisition  (balance  flexibility  of  scope,  schedule,  cost) 

-  Leveraging  of  existing  solutions  (e.g.  software  libraries)  (OA) 

-  Open  competition  among  many  solution  suppliers  (OA) 


Conclusions 


•  ARCI  has  demonstrated  the  potential  to  radically  improve 
acquisition  performance  in  continuous-upgrade  programs 

•  Implementing  ARCI  lessons  into  RCIP  for  broader  use 
requires  the  further  development  of  new  acquisition 
processes,  changes  in  supplier  roles,  and  development  of 
different  program  management  skills 

•  Successfully  implementing  RCIP  can  greatly  improve 
acquisition  program  effectiveness  and  efficiency  and 

provide  a  basis  for  widespread  adoption. 
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Questions? 

Comments? 

Discussion? 


Analysis  of  the  ARCI  Program 

Atypical  Program  Environment 


•  Fleet  need  for  fast  capability  improvement 

-  Extensive  and  direct  involvement  by  warfighters 

-  Strong  support  by  fleet  upon  demonstration  of  improvement 

•  Very  limited  funding 

-  Encouraged  use  of  COTS  (enormous  savings) 

•  Many  available  off-the-shelf  technologies  &  designs 

-  Encouraged  use  of  COTS  (provided  selection  flex.) 

•  Era  of  acquisition  reform 


Reduced  oversight 


Analysis  of  the  ARCI  Program 

Atypical  Program  Design  Features 


•  Fixed  and  frequent  capability  improvements 

-  Facilitated  delaying  requirement  fulfillment  until  mature 

•  Extensive  use  of  developed  technologies  &  designs 

-  Added  capacity  &capabilities  developed  since  original  development 

-  Added  flexibility  for  future  upgrades  and  meeting  extra-COTS  requirements 

-  Many  suppliers:  ONR,  academia,  small  businesses 

•  Extensive  replacement  of  legacy  systems  with  COTS 

-  Inherently  modular  -  accelerated  upgrades 

•  Continuous  warfighter  involvement  in  acquisition 

-  Improved  development  due  to  realistic  operations  input  to  acquisition 

-  Provided  typically-unavailable  operations  data  for  testing  and  development 

-  Built  fleet  sunnort  throuuh  narticination 


Analysis  of  the  ARCI  Program 

Atypical  Program  Management 


•  Redesigned  supplier  relations  and  processes 

-  Prime  contractor  in  coordinator  role  only  -  not  supplier 

-  Repeated  open  competitions  (&  objective  solution  evaluations) 

•  Maturity  was  the  basis  for  upgrade  scope 

-  “Pull”  resource  allocation  based  on  needs  vs.  “Push”  of  requirements 

-  Identify  and  select  mature  solutions  at  start  of  integration 

•  Continuous  requirements  development, 


technology  development,  and  design 

-  Not  tightly  linked  to  program  schedule 

-  Upgrade  content  decisions  &  commitments  late  vs.  early 


ARCI's  Atypical  Objectives  - 

A  Notional  Model 


•  When  resources  constrain  progress,  what 
performance  dimension  is  most  flexible? 
Ranking  from  least  flexible  to  most  flexible... 

•  Traditional  programs: 

1. %  Requirements  filled 

2.  Cost 

3.  Schedule 


•  ARCI: 

1.  Schedule  (no  delaying  of  builds) 

2.  Cost 

3. %  Requirements  filled  (in  this  build) 
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A  Simulation  Model  of  ARCI 


•  ARCI  acquisition  process 

•  Six  resource  types 

-  Technology  acquisition,  design,  integration 

-  Program  management  (govt.)  and  suppliers 


Months  from  Initial  Requirements  Release 

O  3  6  9  12  15  18  21  24  27  30  33  36  39  42  45  48  51  54  57  60 


Requirements  Evolution 


Acquire  Technologies 


Acquire  Designs 


Integrate  Designs  into  Upgrades 

Towed  array  upgrade 


Hull  array  upgrade  release 


Spherical  array  upgrade 


High  frequency  array 
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Total  Work  Packages 
Released  to  Fleet 


RCIP  Implementation  Challenges 

Implications  for  Design  and  Practice 


Project  Integration  Work  Released  :  RCIP  Opportunity- 
Project  Integration  Work  Released  :  RCIP  Challenges — 


work  packages 
work  packages 


Cumulative  RCIP  Performance  without  and  with  Implementation  Issues 
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